   This file documents Gnus, the GNU Emacs newsreader.

   Copyright (C) 1995,96 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the entire resulting derived work is distributed under the terms
of a permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions.

Red Gnus
........

   New features in Gnus 5.4/5.5:

   * `nntp.el' has been totally rewritten in an asynchronous fashion.

   * Article prefetching functionality has been moved up into Gnus
     (see Asynchronous Fetching.).

   * Scoring can now be performed with logical operators like `and',
     `or', `not', and parent redirection (see Advanced Scoring.).

   * Article washing status can be displayed in the article mode line
     (see Misc Article.).

   * `gnus.el' has been split into many smaller files.

   * Suppression of duplicate articles based on Message-ID can be done
     (see Duplicate Suppression.).

          (setq gnus-suppress-duplicates t)

   * New variables for specifying what score and adapt files are to be
     considered home score and adapt files (see Home Score File.)
     have been added.

   * `nndoc' was rewritten to be easily extendable (see Document Server Internals.).

   * Groups can inherit group parameters from parent topics (see
     Topic Parameters.).

   * Article editing has been revamped and is now actually usable.

   * Signatures can be recognized in more intelligent fashions (see
     Article Signature.).

   * Summary pick mode has been made to look more `nn'-like.  Line
     numbers are displayed and the `.' command can be used to pick
     articles (`Pick and Read').

   * Commands for moving the `.newsrc.eld' from one server to another
     have been added (see Changing Servers.).

   * There's a way now to specify that "uninteresting" fields be
     suppressed when generating lines in buffers (see Advanced Formatting.).

   * Several commands in the group buffer can be undone with `M-C-_'
     (see Undo.).

   * Scoring can be done on words using the new score type `w' (see
     Score File Format.).

   * Adaptive scoring can be done on a Subject word-by-word basis
     (see Adaptive Scoring.).

          (setq gnus-use-adaptive-scoring '(word))

   * Scores can be decayed (see Score Decays.).

          (setq gnus-decay-scores t)

   * Scoring can be performed using a regexp on the Date header.  The
     Date is normalized to compact ISO 8601 format first (see Score File Format.).

   * A new command has been added to remove all data on articles from
     the native server (see Changing Servers.).

   * A new command for reading collections of documents (`nndoc' with
     `nnvirtual' on top) has been added--`M-C-d' (see Really Various Summary Commands.).

   * Process mark sets can be pushed and popped (see Setting Process Marks.).

   * A new mail-to-news backend makes it possible to post even when the
     NNTP server doesn't allow posting (see Mail-To-News Gateways.).

   * A new backend for reading searches from Web search engines
     ("DejaNews", "Alta Vista", "InReference") has been added (see
     Web Searches.).

   * Groups inside topics can now be sorted using the standard sorting
     functions, and each topic can be sorted independently (see Topic Sorting.).

   * Subsets of the groups can be sorted independently (`Sorting
     Groups').

   * Cached articles can be pulled into the groups (see Summary Generation Commands.).

   * Score files are now applied in a more reliable order (see Score Variables.).

   * Reports on where mail messages end up can be generated (see
     Splitting Mail.).

   * More hooks and functions have been added to remove junk from
     incoming mail before saving the mail (see Washing Mail.).

   * Emphasized text can be properly fontisized:

          (add-hook 'gnus-article-display-hook 'gnus-article-emphasize)

Newest Features
---------------

   Also known as the "todo list".  Sure to be implemented before the
next millennium.

   Be afraid.  Be very afraid.

   * Native MIME support is something that should be done.

   * Really do unbinhexing.

   And much, much, much more.  There is more to come than has already
been implemented.  (But that's always true, isn't it?)

   `<URL:http://www.ifi.uio.no/~larsi/rgnus/todo>' is where the actual
up-to-the-second todo list is located, so if you're really curious, you
could point your Web browser over that-a-way.

Terminology
===========

"news"
     This is what you are supposed to use this thing for--reading news.
     News is generally fetched from a nearby NNTP server, and is
     generally publicly available to everybody.  If you post news, the
     entire world is likely to read just what you have written, and
     they'll all snigger mischievously.  Behind your back.

"mail"
     Everything that's delivered to you personally is mail.  Some
     news/mail readers (like Gnus) blur the distinction between mail
     and news, but there is a difference.  Mail is private.  News is
     public.  Mailing is not posting, and replying is not following up.

"reply"
     Send a mail to the person who has written what you are reading.

"follow up"
     Post an article to the current newsgroup responding to the article
     you are reading.

"backend"
     Gnus gets fed articles from a number of backends, both news and
     mail backends.  Gnus does not handle the underlying media, so to
     speak--this is all done by the backends.

"native"
     Gnus will always use one method (and backend) as the "native", or
     default, way of getting news.

"foreign"
     You can also have any number of foreign groups active at the same
     time.  These are groups that use non-native non-secondary backends
     for getting news.

"secondary"
     Secondary backends are somewhere half-way between being native and
     being foreign, but they mostly act like they are native.

"article"
     A message that has been posted as news.

"mail message"
     A message that has been mailed.

"message"
     A mail message or news article

"head"
     The top part of a message, where administrative information (etc.)
     is put.

"body"
     The rest of an article.  Everything not in the head is in the body.

"header"
     A line from the head of an article.

"headers"
     A collection of such lines, or a collection of heads.  Or even a
     collection of NOV lines.

"NOV"
     When Gnus enters a group, it asks the backend for the headers of
     all unread articles in the group.  Most servers support the News
     OverView format, which is more compact and much faster to read and
     parse than the normal HEAD format.

"level"
     Each group is subscribed at some "level" or other (1-9).  The ones
     that have a lower level are "more" subscribed than the groups with
     a higher level.  In fact, groups on levels 1-5 are considered
     "subscribed"; 6-7 are "unsubscribed"; 8 are "zombies"; and 9 are
     "killed".  Commands for listing groups and scanning for new
     articles will all use the numeric prefix as "working level".

"killed groups"
     No information on killed groups is stored or updated, which makes
     killed groups much easier to handle than subscribed groups.

"zombie groups"
     Just like killed groups, only slightly less dead.

"active file"
     The news server has to keep track of what articles it carries, and
     what groups exist.  All this information in stored in the active
     file, which is rather large, as you might surmise.

"bogus groups"
     A group that exists in the `.newsrc' file, but isn't known to the
     server (i.e.,  it isn't in the active file), is a *bogus group*.
     This means that the group probably doesn't exist (any more).

"server"
     A machine one can connect to and get news (or mail) from.

"select method"
     A structure that specifies the backend, the server and the virtual
     server parameters.

"virtual server"
     A named select method.  Since a select method defines all there is
     to know about connecting to a (physical) server, taking the thing
     as a whole is a virtual server.

"washing"
     Taking a buffer and running it through a filter of some sort.  The
     result will (more often than not) be cleaner and more pleasing
     than the original.

"ephemeral groups"
     Most groups store data on what articles you have read.  "Ephemeral"
     groups are groups that will have no data stored--when you exit the
     group, it'll disappear into the aether.

"solid groups"
     This is the opposite of ephemeral groups.  All groups listed in the
     group buffer are solid groups.

"sparse articles"
     These are article placeholders shown in the summary buffer when
     `gnus-build-sparse-threads' has been switched on.

Customization
=============

   All variables are properly documented elsewhere in this manual.  This
section is designed to give general pointers on how to customize Gnus
for some quite common situations.

Slow/Expensive NNTP Connection
------------------------------

   If you run Emacs on a machine locally, and get your news from a
machine over some very thin strings, you want to cut down on the amount
of data Gnus has to get from the NNTP server.

`gnus-read-active-file'
     Set this to `nil', which will inhibit Gnus from requesting the
     entire active file from the server.  This file is often v.  large.
     You also have to set `gnus-check-new-newsgroups' and
     `gnus-check-bogus-newsgroups' to `nil' to make sure that Gnus
     doesn't suddenly decide to fetch the active file anyway.

`gnus-nov-is-evil'
     This one has to be `nil'.  If not, grabbing article headers from
     the NNTP server will not be very fast.  Not all NNTP servers
     support XOVER; Gnus will detect this by itself.

Slow Terminal Connection
------------------------

   Let's say you use your home computer for dialing up the system that
runs Emacs and Gnus.  If your modem is slow, you want to reduce (as
much as possible) the amount of data sent over the wires.

`gnus-auto-center-summary'
     Set this to `nil' to inhibit Gnus from re-centering the summary
     buffer all the time.  If it is `vertical', do only vertical
     re-centering.  If it is neither `nil' nor `vertical', do both
     horizontal and vertical recentering.

`gnus-visible-headers'
     Cut down on the headers included in the articles to the minimum.
     You can, in fact, make do without them altogether--most of the
     useful data is in the summary buffer, anyway.  Set this variable to
     `^NEVVVVER' or `From:', or whatever you feel you need.

`gnus-article-display-hook'
     Set this hook to all the available hiding commands:
          (setq gnus-article-display-hook
                '(gnus-article-hide-headers gnus-article-hide-signature
                  gnus-article-hide-citation))

`gnus-use-full-window'
     By setting this to `nil', you can make all the windows smaller.
     While this doesn't really cut down much generally, it means that
     you have to see smaller portions of articles before deciding that
     you didn't want to read them anyway.

`gnus-thread-hide-subtree'
     If this is non-`nil', all threads in the summary buffer will be
     hidden initially.

`gnus-updated-mode-lines'
     If this is `nil', Gnus will not put information in the buffer mode
     lines, which might save some time.

Little Disk Space
-----------------

   The startup files can get rather large, so you may want to cut their
sizes a bit if you are running out of space.

`gnus-save-newsrc-file'
     If this is `nil', Gnus will never save `.newsrc'--it will only
     save `.newsrc.eld'.  This means that you will not be able to use
     any other newsreaders than Gnus.  This variable is `t' by default.

`gnus-save-killed-list'
     If this is `nil', Gnus will not save the list of dead groups.  You
     should also set `gnus-check-new-newsgroups' to `ask-server' and
     `gnus-check-bogus-newsgroups' to `nil' if you set this variable to
     `nil'.  This variable is `t' by default.

Slow Machine
------------

   If you have a slow machine, or are just really impatient, there are a
few things you can do to make Gnus run faster.

   Set `gnus-check-new-newsgroups' and `gnus-check-bogus-newsgroups' to
`nil' to make startup faster.

   Set `gnus-show-threads', `gnus-use-cross-reference' and
`gnus-nov-is-evil' to `nil' to make entering and exiting the summary
buffer faster.

   Set `gnus-article-display-hook' to `nil' to make article processing
a bit faster.

Troubleshooting
===============

   Gnus works *so* well straight out of the box--I can't imagine any
problems, really.

   Ahem.

  1. Make sure your computer is switched on.

  2. Make sure that you really load the current Gnus version.  If you
     have been running GNUS, you need to exit Emacs and start it up
     again before Gnus will work.

  3. Try doing an `M-x gnus-version'.  If you get something that looks
     like `Gnus v5.46; nntp 4.0' you have the right files loaded.  If,
     on the other hand, you get something like `NNTP 3.x' or `nntp
     flee', you have some old `.el' files lying around.  Delete these.

  4. Read the help group (`G h' in the group buffer) for a FAQ and a
     how-to.

  5. Gnus works on many recursive structures, and in some extreme (and
     very rare) cases Gnus may recurse down "too deeply" and Emacs will
     beep at you.  If this happens to you, set `max-lisp-eval-depth' to
     500 or something like that.

   If all else fails, report the problem as a bug.

   If you find a bug in Gnus, you can report it with the `M-x gnus-bug'
command. `M-x set-variable RET debug-on-error RET t RET', and send me
the backtrace.  I will fix bugs, but I can only fix them if you send me
a precise description as to how to reproduce the bug.

   You really can never be too detailed in a bug report.  Always use the
`M-x gnus-bug' command when you make bug reports, even if it creates a
10Kb mail each time you use it, and even if you have sent me your
environment 500 times before.  I don't care.  I want the full info each
time.

   It is also important to remember that I have no memory whatsoever.
If you send a bug report, and I send you a reply, and then you just send
back "No, it's not! Moron!", I will have no idea what you are insulting
me about.  Always over-explain everything.  It's much easier for all of
us--if I don't have all the information I need, I will just mail you
and ask for more info, and everything takes more time.

   If the problem you're seeing is very visual, and you can't quite
explain it, copy the Emacs window to a file (with `xwd', for instance),
put it somewhere it can be reached, and include the URL of the picture
in the bug report.

   If you just need help, you are better off asking on
`gnu.emacs.gnus'.  I'm not very helpful.

   You can also ask on the ding mailing list--`ding@gnus.org'.  Write
to `ding-request@gnus.org' to subscribe.

A Programmer's Guide to Gnus
============================

   It is my hope that other people will figure out smart stuff that Gnus
can do, and that other people will write those smart things as well.  To
facilitate that I thought it would be a good idea to describe the inner
workings of Gnus.  And some of the not-so-inner workings, while I'm at
it.

   You can never expect the internals of a program not to change, but I
will be defining (in some details) the interface between Gnus and its
backends (this is written in stone), the format of the score files
(ditto), data structures (some are less likely to change than others)
and general methods of operation.

Gnus Utility Functions
----------------------

   When writing small functions to be run from hooks (and stuff), it's
vital to have access to the Gnus internal functions and variables.
Below is a list of the most common ones.

`gnus-newsgroup-name'
     This variable holds the name of the current newsgroup.

`gnus-find-method-for-group'
     A function that returns the select method for GROUP.

`gnus-group-real-name'
     Takes a full (prefixed) Gnus group name, and returns the unprefixed
     name.

`gnus-group-prefixed-name'
     Takes an unprefixed group name and a select method, and returns
     the full (prefixed) Gnus group name.

`gnus-get-info'
     Returns the group info list for GROUP.

`gnus-add-current-to-buffer-list'
     Adds the current buffer to the list of buffers to be killed on Gnus
     exit.

`gnus-continuum-version'
     Takes a Gnus version string as a parameter and returns a floating
     point number.  Earlier versions will always get a lower number
     than later versions.

`gnus-group-read-only-p'
     Says whether GROUP is read-only or not.

`gnus-news-group-p'
     Says whether GROUP came from a news backend.

`gnus-ephemeral-group-p'
     Says whether GROUP is ephemeral or not.

`gnus-server-to-method'
     Returns the select method corresponding to SERVER.

`gnus-server-equal'
     Says whether two virtual servers are equal.

`gnus-group-native-p'
     Says whether GROUP is native or not.

`gnus-group-secondary-p'
     Says whether GROUP is secondary or not.

`gnus-group-foreign-p'
     Says whether GROUP is foreign or not.

`group-group-find-parameter'
     Returns the parameter list of GROUP.  If given a second parameter,
     returns the value of that parameter for GROUP.

`gnus-group-set-parameter'
     Takes three parameters; GROUP, PARAMETER and VALUE.

`gnus-narrow-to-body'
     Narrows the current buffer to the body of the article.

`gnus-check-backend-function'
     Takes two parameters, FUNCTION and GROUP.  If the backend GROUP
     comes from supports FUNCTION, return non-`nil'.

          (gnus-check-backend-function "request-scan" "nnml:misc")
          => t

`gnus-read-method'
     Prompts the user for a select method.

Backend Interface
-----------------

   Gnus doesn't know anything about NNTP, spools, mail or virtual
groups.  It only knows how to talk to "virtual servers".  A virtual
server is a "backend" and some "backend variables".  As examples of the
first, we have `nntp', `nnspool' and `nnmbox'.  As examples of the
latter we have `nntp-port-number' and `nnmbox-directory'.

   When Gnus asks for information from a backend--say `nntp'--on
something, it will normally include a virtual server name in the
function parameters.  (If not, the backend should use the "current"
virtual server.)  For instance, `nntp-request-list' takes a virtual
server as its only (optional) parameter.  If this virtual server hasn't
been opened, the function should fail.

   Note that a virtual server name has no relation to some physical
server name.  Take this example:

     (nntp "odd-one"
           (nntp-address "ifi.uio.no")
           (nntp-port-number 4324))

   Here the virtual server name is `odd-one' while the name of the
physical server is `ifi.uio.no'.

   The backends should be able to switch between several virtual
servers.  The standard backends implement this by keeping an alist of
virtual server environments that they pull down/push up when needed.

   There are two groups of interface functions: "required functions",
which must be present, and "optional functions", which Gnus will always
check for presence before attempting to call 'em.

   All these functions are expected to return data in the buffer
`nntp-server-buffer' (` *nntpd*'), which is somewhat unfortunately
named, but we'll have to live with it.  When I talk about "resulting
data", I always refer to the data in that buffer.  When I talk about
"return value", I talk about the function value returned by the
function call.  Functions that fail should return `nil' as the return
value.

   Some backends could be said to be "server-forming" backends, and
some might be said not to be.  The latter are backends that generally
only operate on one group at a time, and have no concept of "server" -
they have a group, and they deliver info on that group and nothing more.

   In the examples and definitions I will refer to the imaginary backend
`nnchoke'.

Required Backend Functions
..........................

`(nnchoke-retrieve-headers ARTICLES &optional GROUP SERVER FETCH-OLD)'
     ARTICLES is either a range of article numbers or a list of
     `Message-ID's.  Current backends do not fully support either--only
     sequences (lists) of article numbers, and most backends do not
     support retrieval of `Message-ID's.  But they should try for both.

     The result data should either be HEADs or NOV lines, and the result
     value should either be `headers' or `nov' to reflect this.  This
     might later be expanded to `various', which will be a mixture of
     HEADs and NOV lines, but this is currently not supported by Gnus.

     If FETCH-OLD is non-`nil' it says to try fetching "extra headers",
     in some meaning of the word.  This is generally done by fetching
     (at most) FETCH-OLD extra headers less than the smallest article
     number in `articles', and filling the gaps as well.  The presence
     of this parameter can be ignored if the backend finds it
     cumbersome to follow the request.  If this is non-`nil' and not a
     number, do maximum fetches.

     Here's an example HEAD:

          221 1056 Article retrieved.
          Path: ifi.uio.no!sturles
          From: sturles@ifi.uio.no (Sturle Sunde)
          Newsgroups: ifi.discussion
          Subject: Re: Something very droll
          Date: 27 Oct 1994 14:02:57 +0100
          Organization: Dept. of Informatics, University of Oslo, Norway
          Lines: 26
          Message-ID: <38o8e1$a0o@holmenkollen.ifi.uio.no>
          References: <38jdmq$4qu@visbur.ifi.uio.no>
          NNTP-Posting-Host: holmenkollen.ifi.uio.no
          .

     So a `headers' return value would imply that there's a number of
     these in the data buffer.

     Here's a BNF definition of such a buffer:

          headers        = *head
          head           = error / valid-head
          error-message  = [ "4" / "5" ] 2number " " <error message> eol
          valid-head     = valid-message *header "." eol
          valid-message  = "221 " <number> " Article retrieved." eol
          header         = <text> eol

     If the return value is `nov', the data buffer should contain
     "network overview database" lines.  These are basically fields
     separated by tabs.

          nov-buffer = *nov-line
          nov-line   = 8*9 [ field <TAB> ] eol
          field      = <text except TAB>

     For a closer look at what should be in those fields, see
     Headers..

`(nnchoke-open-server SERVER &optional DEFINITIONS)'
     SERVER is here the virtual server name.  DEFINITIONS is a list of
     `(VARIABLE VALUE)' pairs that define this virtual server.

     If the server can't be opened, no error should be signaled.  The
     backend may then choose to refuse further attempts at connecting
     to this server.  In fact, it should do so.

     If the server is opened already, this function should return a
     non-`nil' value.  There should be no data returned.

`(nnchoke-close-server &optional SERVER)'
     Close connection to SERVER and free all resources connected to it.
     Return `nil' if the server couldn't be closed for some reason.

     There should be no data returned.

`(nnchoke-request-close)'
     Close connection to all servers and free all resources that the
     backend have reserved.  All buffers that have been created by that
     backend should be killed.  (Not the `nntp-server-buffer', though.)
     This function is generally only called when Gnus is shutting down.

     There should be no data returned.

`(nnchoke-server-opened &optional SERVER)'
     If SERVER is the current virtual server, and the connection to the
     physical server is alive, then this function should return a
     non-`nil' vlue.  This function should under no circumstances
     attempt to reconnect to a server we have lost connection to.

     There should be no data returned.

`(nnchoke-status-message &optional SERVER)'
     This function should return the last error message from SERVER.

     There should be no data returned.

`(nnchoke-request-article ARTICLE &optional GROUP SERVER TO-BUFFER)'
     The result data from this function should be the article specified
     by ARTICLE.  This might either be a `Message-ID' or a number.  It
     is optional whether to implement retrieval by `Message-ID', but it
     would be nice if that were possible.

     If TO-BUFFER is non-`nil', the result data should be returned in
     this buffer instead of the normal data buffer.  This is to make it
     possible to avoid copying large amounts of data from one buffer to
     another, while Gnus mainly requests articles to be inserted
     directly into its article buffer.

     If it is at all possible, this function should return a cons cell
     where the `car' is the group name the article was fetched from,
     and the `cdr' is the article number.  This will enable Gnus to
     find out what the real group and article numbers are when fetching
     articles by `Message-ID'.  If this isn't possible, `t' should be
     returned on successful article retrieval.

`(nnchoke-request-group GROUP &optional SERVER FAST)'
     Get data on GROUP.  This function also has the side effect of
     making GROUP the current group.

     If FAST, don't bother to return useful data, just make GROUP the
     current group.

     Here's an example of some result data and a definition of the same:

          211 56 1000 1059 ifi.discussion

     The first number is the status, which should be 211.  Next is the
     total number of articles in the group, the lowest article number,
     the highest article number, and finally the group name.  Note that
     the total number of articles may be less than one might think
     while just considering the highest and lowest article numbers, but
     some articles may have been canceled.  Gnus just discards the
     total-number, so whether one should take the bother to generate it
     properly (if that is a problem) is left as an exercise to the
     reader.

          group-status = [ error / info ] eol
          error        = [ "4" / "5" ] 2<number> " " <Error message>
          info         = "211 " 3* [ <number> " " ] <string>

`(nnchoke-close-group GROUP &optional SERVER)'
     Close GROUP and free any resources connected to it.  This will be
     a no-op on most backends.

     There should be no data returned.

`(nnchoke-request-list &optional SERVER)'
     Return a list of all groups available on SERVER.  And that means
     *all*.

     Here's an example from a server that only carries two groups:

          ifi.test 0000002200 0000002000 y
          ifi.discussion 3324 3300 n

     On each line we have a group name, then the highest article number
     in that group, the lowest article number, and finally a flag.

          active-file = *active-line
          active-line = name " " <number> " " <number> " " flags eol
          name        = <string>
          flags       = "n" / "y" / "m" / "x" / "j" / "=" name

     The flag says whether the group is read-only (`n'), is moderated
     (`m'), is dead (`x'), is aliased to some other group
     (`=other-group') or none of the above (`y').

`(nnchoke-request-post &optional SERVER)'
     This function should post the current buffer.  It might return
     whether the posting was successful or not, but that's not
     required.  If, for instance, the posting is done asynchronously,
     it has generally not been completed by the time this function
     concludes.  In that case, this function should set up some kind of
     sentinel to beep the user loud and clear if the posting could not
     be completed.

     There should be no result data from this function.

Optional Backend Functions
..........................

`(nnchoke-retrieve-groups GROUPS &optional SERVER)'
     GROUPS is a list of groups, and this function should request data
     on all those groups.  How it does it is of no concern to Gnus, but
     it should attempt to do this in a speedy fashion.

     The return value of this function can be either `active' or
     `group', which says what the format of the result data is.  The
     former is in the same format as the data from
     `nnchoke-request-list', while the latter is a buffer full of lines
     in the same format as `nnchoke-request-group' gives.

          group-buffer = *active-line / *group-status

`(nnchoke-request-update-info GROUP INFO &optional SERVER)'
     A Gnus group info (see Group Info.) is handed to the backend
     for alterations.  This comes in handy if the backend really
     carries all the information (as is the case with virtual and imap
     groups).  This function should destructively alter the info to
     suit its needs, and should return the (altered) group info.

     There should be no result data from this function.

`(nnchoke-request-type GROUP &optional ARTICLE)'
     When the user issues commands for "sending news" (`F' in the
     summary buffer, for instance), Gnus has to know whether the
     article the user is following up on is news or mail.  This
     function should return `news' if ARTICLE in GROUP is news, `mail'
     if it is mail and `unknown' if the type can't be decided.  (The
     ARTICLE parameter is necessary in `nnvirtual' groups which might
     very well combine mail groups and news groups.)  Both GROUP and
     ARTICLE may be `nil'.

     There should be no result data from this function.

`(nnchoke-request-update-mark GROUP ARTICLE MARK)'
     If the user tries to set a mark that the backend doesn't like, this
     function may change the mark.  Gnus will use whatever this function
     returns as the mark for ARTICLE instead of the original MARK.  If
     the backend doesn't care, it must return the original MARK, and
     not `nil' or any other type of garbage.

     The only use for this I can see is what `nnvirtual' does with
     it--if a component group is auto-expirable, marking an article as
     read in the virtual group should result in the article being
     marked as expirable.

     There should be no result data from this function.

`(nnchoke-request-scan &optional GROUP SERVER)'
     This function may be called at any time (by Gnus or anything else)
     to request that the backend check for incoming articles, in one
     way or another.  A mail backend will typically read the spool file
     or query the POP server when this function is invoked.  The GROUP
     doesn't have to be heeded--if the backend decides that it is too
     much work just scanning for a single group, it may do a total scan
     of all groups.  It would be nice, however, to keep things local if
     that's practical.

     There should be no result data from this function.

`(nnchoke-request-group-description GROUP &optional SERVER)'
     The result data from this function should be a description of
     GROUP.

          description-line = name <TAB> description eol
          name             = <string>
          description      = <text>

`(nnchoke-request-list-newsgroups &optional SERVER)'
     The result data from this function should be the description of all
     groups available on the server.

          description-buffer = *description-line

`(nnchoke-request-newgroups DATE &optional SERVER)'
     The result data from this function should be all groups that were
     created after `date', which is in normal human-readable date
     format.  The data should be in the active buffer format.

`(nnchoke-request-create-group GROUP &optional SERVER)'
     This function should create an empty group with name GROUP.

     There should be no return data.

`(nnchoke-request-expire-articles ARTICLES &optional GROUP SERVER FORCE)'
     This function should run the expiry process on all articles in the
     ARTICLES range (which is currently a simple list of article
     numbers.)  It is left up to the backend to decide how old articles
     should be before they are removed by this function.  If FORCE is
     non-`nil', all ARTICLES should be deleted, no matter how new they
     are.

     This function should return a list of articles that it did not/was
     not able to delete.

     There should be no result data returned.

`(nnchoke-request-move-article ARTICLE GROUP SERVER ACCEPT-FORM'
     &optional LAST)

     This function should move ARTICLE (which is a number) from GROUP
     by calling ACCEPT-FORM.

     This function should ready the article in question for moving by
     removing any header lines it has added to the article, and
     generally should "tidy up" the article.  Then it should `eval'
     ACCEPT-FORM in the buffer where the "tidy" article is.  This will
     do the actual copying.  If this `eval' returns a non-`nil' value,
     the article should be removed.

     If LAST is `nil', that means that there is a high likelihood that
     there will be more requests issued shortly, so that allows some
     optimizations.

     The function should return a cons where the `car' is the group
     name and the `cdr' is the article number that the article was
     entered as.

     There should be no data returned.

`(nnchoke-request-accept-article GROUP &optional SERVER LAST)'
     This function takes the current buffer and inserts it into GROUP.
     If LAST in `nil', that means that there will be more calls to this
     function in short order.

     The function should return a cons where the `car' is the group
     name and the `cdr' is the article number that the article was
     entered as.

     There should be no data returned.

`(nnchoke-request-replace-article ARTICLE GROUP BUFFER)'
     This function should remove ARTICLE (which is a number) from GROUP
     and insert BUFFER there instead.

     There should be no data returned.

`(nnchoke-request-delete-group GROUP FORCE &optional SERVER)'
     This function should delete GROUP.  If FORCE, it should really
     delete all the articles in the group, and then delete the group
     itself.  (If there is such a thing as "the group itself".)

     There should be no data returned.

`(nnchoke-request-rename-group GROUP NEW-NAME &optional SERVER)'
     This function should rename GROUP into NEW-NAME.  All articles in
     GROUP should move to NEW-NAME.

     There should be no data returned.

Error Messaging
...............

   The backends should use the function `nnheader-report' to report
error conditions--they should not raise errors when they aren't able to
perform a request.  The first argument to this function is the backend
symbol, and the rest are interpreted as arguments to `format' if there
are multiple of them, or just a string if there is one of them.  This
function must always returns `nil'.

     (nnheader-report 'nnchoke "You did something totally bogus")

     (nnheader-report 'nnchoke "Could not request group %s" group)

   Gnus, in turn, will call `nnheader-get-report' when it gets a `nil'
back from a server, and this function returns the most recently
reported message for the backend in question.  This function takes one
argument--the server symbol.

   Internally, these functions access BACKEND`-status-string', so the
`nnchoke' backend will have its error message stored in
`nnchoke-status-string'.

Writing New Backends
....................

   Many backends are quite similar.  `nnml' is just like `nnspool', but
it allows you to edit the articles on the server.  `nnmh' is just like
`nnml', but it doesn't use an active file, and it doesn't maintain
overview databases.  `nndir' is just like `nnml', but it has no concept
of "groups", and it doesn't allow editing articles.

   It would make sense if it were possible to "inherit" functions from
backends when writing new backends.  And, indeed, you can do that if you
want to.  (You don't have to if you don't want to, of course.)

   All the backends declare their public variables and functions by
using a package called `nnoo'.

   To inherit functions from other backends (and allow other backends to
inherit functions from the current backend), you should use the
following macros:

`nnoo-declare'
     This macro declares the first parameter to be a child of the
     subsequent parameters.  For instance:

          (nnoo-declare nndir
            nnml nnmh)

     `nndir' has declared here that it intends to inherit functions from
     both `nnml' and `nnmh'.

`defvoo'
     This macro is equivalent to `defvar', but registers the variable as
     a public server variable.  Most state-oriented variables should be
     declared with `defvoo' instead of `defvar'.

     In addition to the normal `defvar' parameters, it takes a list of
     variables in the parent backends to map the variable to when
     executing a function in those backends.

          (defvoo nndir-directory nil
            "Where nndir will look for groups."
            nnml-current-directory nnmh-current-directory)

     This means that `nnml-current-directory' will be set to
     `nndir-directory' when an `nnml' function is called on behalf of
     `nndir'.  (The same with `nnmh'.)

`nnoo-define-basics'
     This macro defines some common functions that almost all backends
     should have.

          (nnoo-define-basics nndir)

`deffoo'
     This macro is just like `defun' and takes the same parameters.  In
     addition to doing the normal `defun' things, it registers the
     function as being public so that other backends can inherit it.

`nnoo-map-functions'
     This macro allows mapping of functions from the current backend to
     functions from the parent backends.

          (nnoo-map-functions nndir
            (nnml-retrieve-headers 0 nndir-current-group 0 0)
            (nnmh-request-article 0 nndir-current-group 0 0))

     This means that when `nndir-retrieve-headers' is called, the first,
     third, and fourth parameters will be passed on to
     `nnml-retrieve-headers', while the second parameter is set to the
     value of `nndir-current-group'.

`nnoo-import'
     This macro allows importing functions from backends.  It should be
     the last thing in the source file, since it will only define
     functions that haven't already been defined.

          (nnoo-import nndir
            (nnmh
             nnmh-request-list
             nnmh-request-newgroups)
            (nnml))

     This means that calls to `nndir-request-list' should just be passed
     on to `nnmh-request-list', while all public functions from `nnml'
     that haven't been defined in `nndir' yet should be defined now.

   Below is a slightly shortened version of the `nndir' backend.

     ;;; nndir.el --- single directory newsgroup access for Gnus
     ;; Copyright (C) 1995,96 Free Software Foundation, Inc.

     ;;; Code:

     (require 'nnheader)
     (require 'nnmh)
     (require 'nnml)
     (require 'nnoo)
     (eval-when-compile (require 'cl))

     (nnoo-declare nndir
       nnml nnmh)

     (defvoo nndir-directory nil
       "Where nndir will look for groups."
       nnml-current-directory nnmh-current-directory)

     (defvoo nndir-nov-is-evil nil
       "*Non-nil means that nndir will never retrieve NOV headers."
       nnml-nov-is-evil)

     (defvoo nndir-current-group "" nil nnml-current-group nnmh-current-group)
     (defvoo nndir-top-directory nil nil nnml-directory nnmh-directory)
     (defvoo nndir-get-new-mail nil nil nnml-get-new-mail nnmh-get-new-mail)

     (defvoo nndir-status-string "" nil nnmh-status-string)
     (defconst nndir-version "nndir 1.0")

     ;;; Interface functions.

     (nnoo-define-basics nndir)

     (deffoo nndir-open-server (server &optional defs)
       (setq nndir-directory
             (or (cadr (assq 'nndir-directory defs))
                 server))
       (unless (assq 'nndir-directory defs)
         (push `(nndir-directory ,server) defs))
       (push `(nndir-current-group
               ,(file-name-nondirectory (directory-file-name nndir-directory)))
             defs)
       (push `(nndir-top-directory
               ,(file-name-directory (directory-file-name nndir-directory)))
             defs)
       (nnoo-change-server 'nndir server defs))

     (nnoo-map-functions nndir
       (nnml-retrieve-headers 0 nndir-current-group 0 0)
       (nnmh-request-article 0 nndir-current-group 0 0)
       (nnmh-request-group nndir-current-group 0 0)
       (nnmh-close-group nndir-current-group 0))

     (nnoo-import nndir
       (nnmh
        nnmh-status-message
        nnmh-request-list
        nnmh-request-newgroups))

     (provide 'nndir)

Hooking New Backends Into Gnus
..............................

   Having Gnus start using your new backend is rather easy--you just
declare it with the `gnus-declare-backend' functions.  This will enter
the backend into the `gnus-valid-select-methods' variable.

   `gnus-declare-backend' takes two parameters--the backend name and an
arbitrary number of "abilities".

   Here's an example:

     (gnus-declare-backend "nnchoke" 'mail 'respool 'address)

   The abilities can be:

`mail'
     This is a mailish backend--followups should (probably) go via mail.

`post'
     This is a newsish backend--followups should (probably) go via news.

`post-mail'
     This backend supports both mail and news.

`none'
     This is neither a post nor mail backend--it's something completely
     different.

`respool'
     It supports respooling--or rather, it is able to modify its source
     articles and groups.

`address'
     The name of the server should be in the virtual server name.  This
     is true for almost all backends.

`prompt-address'
     The user should be prompted for an address when doing commands like
     `B' in the group buffer.  This is true for backends like `nntp',
     but not `nnmbox', for instance.

Mail-like Backends
..................

   One of the things that separate the mail backends from the rest of
the backends is the heavy dependence by the mail backends on common
functions in `nnmail.el'.  For instance, here's the definition of
`nnml-request-scan':

     (deffoo nnml-request-scan (&optional group server)
       (setq nnml-article-file-alist nil)
       (nnmail-get-new-mail 'nnml 'nnml-save-nov nnml-directory group))

   It simply calls `nnmail-get-new-mail' with a few parameters, and
`nnmail' takes care of all the moving and splitting of the mail.

   This function takes four parameters.

METHOD
     This should be a symbol to designate which backend is responsible
     for the call.

EXIT-FUNCTION
     This function should be called after the splitting has been
     performed.

TEMP-DIRECTORY
     Where the temporary files should be stored.

GROUP
     This optional argument should be a group name if the splitting is
     to be performed for one group only.

   `nnmail-get-new-mail' will call BACKEND`-save-mail' to save each
article.  BACKEND`-active-number' will be called to find the article
number assigned to this article.

   The function also uses the following variables:
BACKEND`-get-new-mail' (to see whether to get new mail for this
backend); and BACKEND`-group-alist' and BACKEND`-active-file' to
generate the new active file.  BACKEND`-group-alist' should be a
group-active alist, like this:

     (("a-group" (1 . 10))
      ("some-group" (34 . 39)))